• api/v1alpha1/zz_generated.deepcopy.go: Generated file

internal/webhook/v1alpha1/pluginpreset_webhook.go:144

• convertPresetToPluginOptionValues assigns ov.ValueFrom even when pv.ValueFrom.Secret is nil (e.g., when the preset uses valueFrom.ref). That produces PluginOptionValues with ValueFrom != nil but ValueFrom.Secret == nil, which can lead to nil-pointer panics in validatePluginOptionValues (it dereferences val.ValueFrom.Secret.* without nil checks) and/or invalid PluginOptionValues being validated.
  internal/controller/plugin/pluginpreset_values_resolver.go:59
• When IntegrationEnabled is false, PluginPreset optionValues using valueFrom.ref will flow through without being resolved. In that case, resolvedValues is built from the preset's ValueFrom.Secret only, leaving a PluginOptionValue with ValueFrom != nil but Secret == nil (because the source was a ref). This violates the Plugin schema (PluginValueFromSource requires secret) and can cause Plugin creation/validation failures. Consider failing fast with a clear error when valueFrom.ref is present but integrationEnabled is disabled (similar to the expression feature gate).
  docs/reference/components/pluginpreset.md:186
• This sentence says that when pluginPreset.expressionEvaluationEnabled is false, the resulting Plugins will keep the expression fields unchanged. However the controller rejects presets that contain expressions when the flag is disabled (and Plugins no longer have an expression field at all), so this behavior description is inaccurate.

CEL expression evaluation in PluginPresets requires the feature flag `pluginPreset.expressionEvaluationEnabled` to be set to `true` in the Greenhouse feature flags ConfigMap.

By default, this flag is `false` if it is unset or invalid, and expressions are not evaluated (the resulting Plugins will keep the `expression` fields unchanged).

charts/manager/templates/webhook/webhooks.yaml:242

• This PR is scoped to PluginPreset value resolution, but this change removes the DELETE operation from the Cluster validating webhook. That alters admission behavior for cluster deletion and seems unrelated/risky unless explicitly intended. If this is not intentional, please restore DELETE here (or document why delete validation is no longer needed).

        operations:
          - CREATE
          - UPDATE
        resources:
          - clusters

internal/webhook/v1alpha1/pluginpreset_webhook_test.go:310

• Two table entries covering expression-only and expression+value cases are commented out, leaving the expression validation behavior partially untested. Given expressions are a core part of PluginPreset behavior, it would be better to adapt and re-enable these cases as part of this PR (or add equivalent coverage elsewhere) so regressions are caught.
  internal/controller/plugin/pluginpreset_values_resolver.go:394
• evaluateCELWithObject creates a new CEL environment on every evaluation. In selector-based references this happens once per matched PluginPreset, which can add noticeable CPU/alloc overhead. Consider constructing the env once (and ideally compiling the expression once) and reusing it across evaluations within a reconciliation.

• api/v1alpha1/zz_generated.deepcopy.go: Generated file

internal/webhook/v1alpha1/plugin_webhook.go:336

• The field path used for secret validation errors points to valueFrom.name / valueFrom.key, but the actual fields are nested under valueFrom.secret. This will surface confusing error locations to users.
  internal/controller/plugin/pluginpreset_values_resolver.go:324
• When expression evaluation is disabled, referenced PluginPresets are converted without applying cluster-specific overrides. This means valueFrom.ref can read stale/default values instead of the overridden values for the target cluster.